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, DETAILED ACTION 

1 . This Final Office Action is responsive to applicant's amendment filed January 31 , 
2005. Applicant's amendment of January 31 , 2005 amended claims 1-5, 7-24 and 26- 
28 and canceled claims' 6 and 25. Currently claims 1-5, 7-24 and 26-28 are pending. 

• i 

Response to Amendment 

2. Applicant's arguments filed on January 31 , 2005 with respect to claims 1-28 have 
been considered but are moot in view of the new ground(s) of rejection. 

I 

| Claim Rejections - 35 USC §112 

3. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

4. Claims 7 and 22 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite and failing to point out and distinctly claim the subject matter which the 
applicant regards as the invention. 

Regarding Claims 7 and 22 , claims 7 and 22 recite the limitation "the stability of 
a project" in Claims 1 and 20 respectively. There is insufficient antecedent basis for this 
limitation in the claim. 



Application/Control Number: 09/760,339 Page 3 

Art Unit: 3623 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1 -5, 7-24 and 26-28 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Paul et al., Software Metrics Knowledge and Databases for Project 
Management (January 1999) in view of Wiegers, Karl, Automating Requirements 
Management (1999). 

Regarding Claims 1 , 20 and 28 Paul et al. teach method and system for 
analyzing and assessing the status (progress) of a project ("...metrics combined with a 
selection of powerful tools, and true integration of these metrics and tools forms the 
foundation of efficient and robust software project management."; Column 2, Paragraph 
1 , Page 265). Paul et al. further teach that "...metrics can be divided into three broad 
categories: management, requirements, and quality." (Column 2, Paragraph 3, Page 
256). Paul et al. further teach that "Requirements and specifications may change 
several times during product development." and that metrics are needed to understand, 
track and manage these and other project changes including the measures of 
"...requirements traceability and requirements stability" (Column 2, Paragraph 5, Page 
256; Figure 2, Page 259). 
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More specifically Paul et al. teach that the method and system for determining 
the status (progress) of a project further comprises: 

- the selection, collection, use and computation of a plurality (at least two) of 
project metrics (parameters) and data, including but not limited to project progress 
metrics and their associated data (Section 2 - Test & Evaluation Metrics Data, Columns 
3-4); 

- the use of data integration and analytical techniques, including multiple 
regression analysis, on a plurality of metrics in order to conduct quality and risk 
assessments (project status, Section 2.1.2 Regression and Principal Component 
Analysis, Page 260; Figure 3); 

- a plurality of techniques, including regression analysis and principal component 
analysis, to identify the correlation among a plurality of metrics thereby determining their 
interdependencies (Section 2.1.2, Page 260); and 

- the utilization of requirement specifications/documents ("Find the total number 
of relational requirements documents."; Table 1 , Page 258; Column 2, Paragraphs 3-6, 
Page 256). 

Paul et al. does not expressly teach the use or computation of correlation 
coefficients, the representation of a requirements document utilizing branches and 
leaves or that the system utilizes a network. 
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Wiegers teaches a plurality of commercially available requirements management 
systems that represent requirement documents utilizing branches and leaves 
("hierarchical requirement trees"; Paragraph 3, Page 3) and are Internet enabled 
(computer network; Table 2). Wiegers teaches a plurality of commercially available 
requirements management methods and systems wherein the systems enable users to 
manage a plurality of project artifacts (e.g. requirement specifications, design 
documents and the like; Reasons to Use a Requirements Management Tool, Pages 1- 
2). 

Wiegers further teaches that the requirements management systems further 
comprise: 

- tracking and reporting project data (status; "Tracking the status of each 
requirement during development supports overall project status tracking."; Paragraph 3, 
Page 2); 

- collecting a plurality of project requirement metrics ("...status, priority, cost, 
stability, and risk."; Paragraph 1 , Page 2); 

- integrating with "problem tracking and project management tools" (e.g. 
Microsoft Project; Paragraph 10, Page 2; Paragraph 1, Page 3); and 

- support for the import, export and parsing of a "rich variety" of file formats 
(Paragraph 7, Page 2). 

More generally Wiegers teaches that these tools have a common set of features 
and capabilities including but not limited to (Table 2, Page 6): 
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- the representation of requirement specifications as "hierarchical requirement 
trees" (Paragraph 3, Page 3); 

- integrating with project management tools (e.g. Microsoft Project; Paragraph 1, 
Page 3); 

- user defined requirement attributes (Paragraph 7, Page 1); 

- Internet integration (Table 2); 

- the utilization of a database to store, query and view collected project data 
(Paragraph 3, Page 1); and 

- parsing a source document to load requirements into a database (Table 2). 

Further as per applicant's own admission the representation of requirement 
specifications (documents) consisting of branches and leaves is old and well known 
("...a leaf, unambiguously, a subsection of a branch. The IEEE 1998-830 standard, a 
widely used requirements template provides an example of this structure."; 
Specification: Page 2, Lines 16-23; Page 3, Lines 1-9). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for determining the status of a project, specifically its 
utilization of project management tools ("...metrics combined with a selection of 
powerful tools... forms the foundation of efficient and robust software project 
management."; Column 2, Paragraph 1, Page 265), as taught by Paul et al. would have 
utilized a commercially available requirements management system (tool) with their 
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ability to manage hierarchical requirements tree over a computer network in view of the 
teachings of Wiegers; the resultant system enabling the user to improve their 
requirements management practices (Wiegers: Paragraph 1, Page 5) and increasing 
their ability to track the status of the project. 

Official notice is taken that it is old and well known in the art that regression 
analysis is a common and well known technique for determining the relationship 
between several independent or predictor variables and a dependent or criterion 
variable and that the degree to which two or more predictors are related to the 
dependent variable is expressed in the correlation coefficient. The regressions 
analysis, further comprising the use of correlation coefficients, providing knowledge of 
the interdependencies can be crucial in predicting the extent perturbations brought 
about by any failures or changes in the project (Section 2.1 .2, Page 260). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project 
wherein analyzing the metrics was conducted through the use of statistical regression 
analysis techniques, as taught by Paul et al., would have included the calculation of 
correlation coefficients. The benefit of such regression analysis being to further assist 
project managers with the critical management decisions regarding risk and quality 
during the life cycle of a software project (Section 3 - Conclusion, Page 263). 
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Regarding Claims 2 and 21 Paul et al. teach the use of a plurality of project 
progress and product metrics for use in analyzing and assessing the status (progress) 
of a project. Further Paul et al. teach determining the total number of relation 
requirements document (Column 2, Paragraphs 3-6, Page 256) and the use of 
classification trees (Section 2.1.4, Page 261-262) for the classifying of a plurality of 
metrics (Column 1 , Paragraph 2, Page 262). 

Paul et al. does not teach the use of the specific project progress parameters as 
claimed. 

Wiegers teaches that the commercially available requirements management 
systems collect, store and analyze a plurality of requirement metrics and attributes 
including but not limited to the date created, version number (i.e. number of revisions), 
status, stability, origin, percent implemented, percent verified, etc. (Paragraph 7, Page 1 
and Paragraphs 1-4, Page 2). 

More specifically Wiegers teaches that the project progress parameters include 
at least one of the following (Paragraph 7, Page 1 and Paragraphs 1-4, Page 2): 

- total number of branches and leaves (number of sections, number of 
requirements; inherent in the percent of requirements implemented, number 
implemented/total number of requirements); 

- number of modifications performed on the branches and leaves (version 
number of the requirement); and 
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- average age of the branches and leaves (date created). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
requirements management systems with their ability to collect, store and analyze a 
plurality of project progress parameters including at least one of the following metrics 
the number of requirements, the number of revisions per requirement and the date that 
the requirement was created in view of the teachings of Wiegers provides the user with 
a more accurate and complete understanding of the progress of a project therefore 
assisting project managers with the critical management decisions regarding risk and 
quality during the life cycle of a project (Paul et al., Section 3 - Conclusion, Page 263). 

Regarding Claims 3 and 22 Paul et al. does not expressly teach the regression 
equations to be used when analyzing the collected metrics data. 

Official notice is taken that the regression equations as claimed are old and well 
known in the art as being among a plurality of equations and approaches available for 
statistical regression analysis. Accordingly, it would have been obvious to one skilled in 
the art at the time of the invention that the method and system for analyzing and 
assessing the progress of a project as taught by Paul et al. would benefit from the use 
of any of the plurality of well known and accepted regression analysis techniques and 
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equations, including the equations as claimed, when analyzing the metric data collected 
in order to provide insight into the progress of a project. 

Regarding Claims 4 and 23 Paul et al. teach the use of a database for the 
collection, storage and analysis of software project progress parameters (metrics; Title; 
Paragraph 1 , Page 256). 

While it is well known and well established that the use of databases by their very 
definition involve the storage and access (insert, update, delete, etc.) of the data stored 
within it Paul et al. does not expressly teach updating of at least one database. 

Wiegers teaches that the plurality of commercially available requirement 
management tools update at least one database with data records generated from 
performing a statistical analysis on the collected data ("...sort, filter or query database"; 
Paragraph 4, Page 2; Paragraph 7, Page 1 ; Paragraphs 1-2, Page 2; Paragraph 4, 
Page 3) and that "A commercial requirements management tool that stores 
requirements in a multi-user database provides a more robust solution." (Paragraph 4, 
Page 1 ; Table 2). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
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requirements management systems with their ability to collect, store and analyze a 
plurality of project progress parameters in a database, in view of the teachings of 
Wiegers provides the user with a more accurate and complete understanding of the 
progress of a project therefore assisting project managers with the critical management 
decisions regarding risk and quality during the life cycle of a project (Paul et al., Section 
3 - Conclusion, Page 263). 

Regarding Claims 5, 10, 1 1 and 24 Paul et al. teach the use of a database to 
collect, store, read, write and analyze project progress parameters as discussed above. 

While it is well known and well established that database management systems 
frequently utilize computer networks Paul et al. does not expressly teach receiving data 
across a network. 

Wiegers teaches a plurality of commercially available requirements management 
systems (tools) wherein the systems utilize databases ("A commercial requirements 
management tool that stores requirements in a multi-user database provides a more 
robust solution." (Paragraph 4, Page 1; Table 2) and are Internet enabled (computer 
network; "Includes web interface for database query, discussion and perhaps updating 
requirement attributes"; Table 2; "The heterogeneous client/server implementation..."; 
Paragraph 5, Page 3). 
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It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
requirement management systems (tools) with their ability to collect, store, analyze and 
access over the Internet a plurality of project progress parameters in view of the 
teachings of Wiegers provides the user with a more accurate and complete 
understanding of the progress of a project therefore assisting project managers with the 
critical management decisions regarding risk and quality during the life cycle of a project 
(Paul et al., Section 3 - Conclusion, Page 263). 

Regarding Claims 7, 15 and 26 Paul et al. does not teach outputting the data 
records to graphically represent the progress of a project. 

Wiegers teaches that the plurality of commercially available requirements 
management systems and methods comprise the ability to graphically display any. of a 
plurality of project progress metrics including but not limited to such metrics as stability, 
progress and the like ("...color coded bars that indicate a requirement's status...", 
Paragraph 4, Page 3; "...can also communicate with Microsoft Project to connect 
individual requirements to project tasks.", Paragraph 1, Page 3; Microsoft Project being 
well known to comprise a plurality of graphical representation regarding the progress of 
projects; "...incorporate non-textual objects such as Microsoft Excel worksheets and 
images into the requirements.", Paragraph 9; Page 2). 
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It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
requirements management systems with their ability to collect, store, analyze and 
graphically display a plurality of project progress parameters in view of the teachings of 
Wiegers provides the user with a more accurate and complete understanding of the 
progress of a project therefore assisting project managers with the critical management 
decisions regarding risk and quality during the life cycle of a project (Paul et al., Section 
3 - Conclusion, Page 263). 

Regarding Claims 8, 19 and 27 Paul et al. teach that use of a plurality of project 
documents (at least one), including but not limited to the utilization of requirement 
specifications/documents ("Find the total number of relational requirements 
documents."; Table 1, Page 258; Column 2, Paragraphs 3-6, Page 256) and project 
components for which project progress parameters are to be collected and analyzed. 

More generally Paul et al. further teach that "...metrics can be divided into three 
broad categories: management, requirements, and quality." (Column 2, Paragraph 3, 
Page 256) and that "Requirements and specifications may change several times during 
product development." therefore metrics are needed to understand, track and manage 
these and other project changes including the measures of "... .requirements traceability 
and requirements stability" (Column 2, Paragraph 5, Page 256; Figure 2, Page 259). 
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Regarding Claim 9 Paul et al. teach a method and system for collecting, storing, 
analyzing/assessing a plurality of project progress metrics as discussed above. 

Paul et al. does not teach that the project data has a tree structure (branches and 
leaves) or the subsequent parsing of the tree project data as claimed. 

Wiegers teaches a plurality of commercially available requirements management 
systems wherein the systems further represent the project requirements (project data) 
utilizing a tree structure and the subsequent parsing of the project data ("...parse an 
SRS..."; Paragraph 8, Page 2; "Parses a source document to load requirements into 
database"; Table 2, Row 1). Wiegers further teaches the collection, storage, analysis 
and graphical display of a plurality of project metrics as discussed above. 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
requirements management systems with their ability to collect, store, analyze and 
graphically display a plurality of project progress parameters and parse structured 
project data into and out of a database in view of the teachings of Wiegers provides the 
user with a more accurate and complete understanding of the progress of a project 
therefore assisting project managers with the critical management decisions regarding 
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risk and quality during the life cycle of a project (Paul et al., Section 3 - Conclusion, 
Page 263). 

Regarding Claim 12 Paul et al. teach the use of regression analysis as a means 
for assessing and analyzing project progress and trends (Paragraph 1 , Page 260). Paul 
et al. further teaches a method and system for assessing and analyzing the progress of 
a project wherein attention is paid to the resources to be allocated, having been 
allocated or available for a project are considered over time (Paragraph 4, Page 256; 
Paragraph 2, Page 260; Conclusion, Page 263). 

Paul et al. is silent on the frequency of the project progress assessments and 
forecasts. 

Official notice is taken that the frequency of assessing and analyzing the 
progress of a project is arbitrary and based on the individual preferences, 
legal/contractual project requirements, experiences, project size, scope and duration or 
any of a plurality other guidelines or schedules. Each assessment and analysis 
providing the user with an opportunity to make decisions related to the management of 
the project's progress, including the balancing of available and utilized resources. 



It would have been obvious to one skilled in the art at the time of the invention to 
utilize the method and system for analyzing and assessing the progress of a project as 
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taught by Paul et al. in any desired frequency including but not limited to the daily 
project progress assessment and forecast, in view of the teachings of official notice, 
wherein the daily analysis and assessment would providing insight (forecasts) into a 
project progress and offer an opportunity to effect any of a plurality project progress 
parameters including the rebalancing of project resources on a daily basis thereby 
providing the user with an opportunity to make decisions and positively effect progress 
of a project. 

Regarding Claim 13 Paul et al. teach the essentially temporal nature of the 
system and method for analyzing and assessing the progress of a project ("..metric data 
is the temporal one."; Column 1 , Paragraph 3, Page 255). More specifically Paul et al. 
teach periodic queries (assessments) can provide timely and accurate information 
leading to good management decisions. Further Paul et al. teaches the dominant 
dimension of metrics data as being a temporal one (Section 1.1 - Simple Queries on 
Software Metrics, Page 255). 

Regarding Claim 1.4 Paul et al. teach a plurality of techniques, including 
regression analysis, to identify the correlation among a plurality of metrics thereby 
determining their interdependencies as discussed above. 

Regarding Claim 16 Paul et al. does not teach representing data records as 
objects. 
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Wiegers teaches a plurality of commercially available requirements management 
systems wherein several of the systems represent data records as objects ("...treats 
individual requirements as objects... Doors stores the change history of individual 
objects, modules..."; Paragraph 4, Page 3; "...treats requirements as objects...."; 
Paragraph 5, Page 4). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
requirement management systems (tools) with their ability to treat project data as 
objects, objects being a well known way for modeling systems and documents, in view 
of the teachings of Wiegers provides the user with an efficient means for managing the 
plurality of artifacts (objects) in the project. 

Regarding Claim 17 Paul et al. method and system for analyzing and assessing 
the progress of a project wherein a plurality of metrics and documents are utilized as 
discussed above. 



While it is the use of content mark up languages to represent documents 
(text/content) in programs such as word processors (e.g. SGML) and Internet browsers 
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documents (HTM L) is well known Paul et al. does not expressly teach that the project is 
formatted according to a content markup language. 

Wiegers teach that the plurality of Internet enabled requirements management 
systems provide users with the ability to manage of a plurality of project data including 
but not limited to a plurality of documents (e.g. code, designs, tests, use cases, 
requirements, etc.; Paragraphs 1-3, Page 1 ; Paragraphs 9-10, Page 2). Wiegers further 
teaches that the requirements management systems integrate with a plurality of well 
known document creation and manipulation tools (Microsoft Word, Microsoft Excel, 
etc.), "support a rich variety of import and export file formats" (Paragraph 7, Page 2) and 
provide document parsing capabilities (Table 2). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. coupled with any one of the plurality of commercially available 
requirements management systems with their ability to manage a plurality of project 
data (documents utilizing a content markup language format being well known), in view 
of the teachings of Wiegers provides the user with an efficient means for managing, 
sharing and representing (formatting, displaying, etc.) the plurality of documents and 
other project data in the project. 
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Regarding Claim 18, claim 18 recites similar limitations to Claim land is therefore 
rejected using the same art and rationale as applied in the rejections of Claim 1 . 
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Conclusion 

Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded 
of the extension of time policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
. mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

- Eiche et al., U.S. Patent No. 6,715,130, teach a method and system for 
estimating metrics of a proposed product from a document (requirements document) 
describing the product. Eiche et al. further teach the use of software requirement 
specifications (requirement documents) wherein the document is represented utilizing 
branches and leaves (hierarchical, tree), stored in a database over a network and is 
parsed. 
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- Rational.com web pages teaches the commercially available Rational 
RequisitePro requirements management system and method. Rational further teaches 
that the RequisitePro requirements management system provides a method for 
determining the status of a project wherein the status is determined based on the a 
plurality of management reports and "requirement metrics" including but not limited to 
stability, progress, status, risk, and a plurality of other factors of a requirements 
document and further wherein the requirements document is represented (structured) 
as branches and leaves (tree). Rational further teaches that the requirements 
management system in Internet enabled, utilizes any of a plurality of commercially 
available databases. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott L. Jarrett whose telephone number is (703) 306- 
5679. The examiner can normally be reached on Monday-Friday, 8:00AM - 5:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hafiz Tariq can be reached on (703) 305-9643. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 



SJ 

4/5/2005 
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